Parameterized Testing is a testing technique in which the same test logic is executed multiple times using different input values. Instead of creating separate test methods for every combination of test data, parameters allow the test framework to supply different values to a reusable test method.
In Selenium automation, parameterized tests are commonly used for testing different usernames, passwords, browsers, URLs, environments, search keywords, user roles, product information, expected results, and other test conditions. TestNG provides features such as @Parameters and @DataProvider for implementing parameterized testing.
Parameterized testing is an important part of data-driven automation because it separates reusable test logic from the values used during test execution.
Course Resource: Selenium Training | Register for Course Demo
Parameterized tests are tests that receive input values from an external or configurable source instead of using fixed values directly inside the test method.
The same test method can therefore execute multiple times with different parameters.
Test Method
|
+---- Test Data 1
|
+---- Test Data 2
|
+---- Test Data 3
|
+---- Test Data 4
|
v
Multiple Test Executions
For example, instead of creating separate login methods for three users, a single login test can receive different username and password values.
Real-world applications need to be tested with many different inputs. Parameterization allows automation engineers to reuse the same test logic while changing only the test data.
Test Data Source
|
v
Parameter / DataProvider
|
v
Parameterized Test Method
|
v
Selenium WebDriver
|
v
Application
|
v
Validation / Assertion
|
v
Test Result
The test framework supplies a particular set of values to the test method, executes the test, and then repeats the process with the next set of values.
Selenium WebDriver performs browser automation, while TestNG can provide the values required by the Selenium test.
For example, Selenium can automate a login page while TestNG provides different usernames and passwords.
TestNG
|
+-- Username
+-- Password
|
v
Selenium Test
|
v
Login Page
|
v
Enter Credentials
|
v
Click Login
|
v
Validate Result
TestNG provides multiple mechanisms for parameterized testing.
| Technique | Purpose | Typical Use |
|---|---|---|
| @Parameters | Pass named configuration values | Browser, URL, environment |
| @DataProvider | Supply multiple test-data sets | Login, search, forms |
| @Optional | Provide a default parameter value | Optional configuration |
| External Data | Read values from files or databases | Large test-data sets |
The @Parameters annotation allows TestNG to receive named parameters from the TestNG XML configuration file.
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
public class LoginTest {
@Test
@Parameters({"username", "password"})
public void loginTest(String username, String password) {
System.out.println(username);
System.out.println(password);
}
}
The parameter names specified in @Parameters must correspond to the names defined in the TestNG XML configuration.
<suite name="Automation Suite">
<test name="Login Test">
<parameter name="username" value="admin"/>
<parameter name="password" value="admin123"/>
<classes>
<class name="LoginTest"/>
</classes>
</test>
</suite>
TestNG reads these values and passes them to the test method.
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
public class ParameterTest {
@Test
@Parameters({"browser", "url"})
public void testApplication(String browser, String url) {
System.out.println("Browser: " + browser);
System.out.println("URL: " + url);
}
}
TestNG XML:
<suite name="Suite">
<test name="Application Test">
<parameter name="browser" value="chrome"/>
<parameter name="url" value="https://example.com"/>
<classes>
<class name="ParameterTest"/>
</classes>
</test>
</suite>
Browser parameterization is useful when the same Selenium test needs to run on different browsers.
@Test
@Parameters("browser")
public void browserTest(String browser) {
System.out.println("Executing test on: " + browser);
}
The XML configuration can provide values such as Chrome, Firefox, or Edge.
Cross-browser testing verifies that an application behaves correctly across different browsers.
<suite name="Cross Browser Suite">
<test name="Chrome Test">
<parameter name="browser" value="chrome"/>
<classes>
<class name="BrowserTest"/>
</classes>
</test>
<test name="Firefox Test">
<parameter name="browser" value="firefox"/>
<classes>
<class name="BrowserTest"/>
</classes>
</test>
<test name="Edge Test">
<parameter name="browser" value="edge"/>
<classes>
<class name="BrowserTest"/>
</classes>
</test>
</suite>
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.edge.EdgeDriver;
import org.testng.annotations.Parameters;
import org.testng.annotations.BeforeMethod;
public class BrowserTest {
WebDriver driver;
@BeforeMethod
@Parameters("browser")
public void setup(String browser) {
if (browser.equalsIgnoreCase("chrome")) {
driver = new ChromeDriver();
} else if (browser.equalsIgnoreCase("firefox")) {
driver = new FirefoxDriver();
} else if (browser.equalsIgnoreCase("edge")) {
driver = new EdgeDriver();
} else {
throw new IllegalArgumentException("Unsupported browser: " + browser);
}
}
}
URLs are often parameterized so that the same test can execute against different environments.
@Test
@Parameters("url")
public void openApplication(String url) {
driver.get(url);
System.out.println("Application URL: " + url);
}
Example environments can include:
| Environment | Example URL |
|---|---|
| Development | https://dev.example.com |
| QA | https://qa.example.com |
| Staging | https://stage.example.com |
| Production | https://www.example.com |
Environment parameterization allows the same test suite to run against different application environments without modifying the test source code.
@Test
@Parameters({"environment", "url"})
public void environmentTest(String environment, String url) {
System.out.println("Environment: " + environment);
System.out.println("URL: " + url);
driver.get(url);
}
<suite name="Environment Suite">
<test name="QA Test">
<parameter name="environment" value="QA"/>
<parameter name="url" value="https://qa.example.com"/>
<classes>
<class name="EnvironmentTest"/>
</classes>
</test>
</suite>
The test source code remains unchanged while the execution environment can be changed through configuration.
Login tests are a common use case for parameterization.
@Test
@Parameters({"username", "password"})
public void loginTest(String username, String password) {
driver.findElement(By.id("username"))
.sendKeys(username);
driver.findElement(By.id("password"))
.sendKeys(password);
driver.findElement(By.id("loginButton"))
.click();
}
For real projects, sensitive credentials should preferably be supplied through secure configuration or secret-management systems rather than being stored as plain text in source-controlled XML.
Search functionality can use parameters for different keywords.
@Test
@Parameters("searchText")
public void searchTest(String searchText) {
driver.findElement(By.id("search"))
.sendKeys(searchText);
driver.findElement(By.id("searchButton"))
.click();
}
Parameterized tests can receive multiple values such as name, email, mobile number, role, and expected result.
@Test
@Parameters({"name", "email", "role"})
public void userTest(
String name,
String email,
String role) {
System.out.println(name);
System.out.println(email);
System.out.println(role);
}
| Feature | @Parameters | @DataProvider |
|---|---|---|
| Main Purpose | Configuration values | Test data |
| Data Source | testng.xml | Java method or external source |
| Multiple Data Sets | Not its primary purpose | Yes |
| Browser Configuration | Very suitable | Possible |
| Login Combinations | Limited | Very suitable |
| Data-Driven Testing | Limited | Designed for it |
| Repeated Invocation | Not inherently | Yes |
When a test needs multiple sets of values, TestNG's @DataProvider is generally more suitable.
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(String username, String password) {
System.out.println(username);
System.out.println(password);
}
Expected results can be supplied along with input data.
@DataProvider(name = "calculatorData")
public Object[][] calculatorData() {
return new Object[][] {
{10, 20, 30},
{5, 5, 10},
{100, 50, 150}
};
}
@Test(dataProvider = "calculatorData")
public void additionTest(
int a,
int b,
int expected) {
int actual = a + b;
Assert.assertEquals(actual, expected);
}
Parameterized testing is useful for validating both valid and invalid input combinations.
@DataProvider(name = "loginScenarios")
public Object[][] loginScenarios() {
return new Object[][] {
{"validUser", "validPass", "success"},
{"invalidUser", "validPass", "invalid username"},
{"validUser", "invalidPass", "invalid password"},
{"", "", "required fields"}
};
}
@Test(dataProvider = "loginScenarios")
public void loginValidationTest(
String username,
String password,
String expectedResult) {
System.out.println("Expected: " + expectedResult);
}
A single test can accept several parameters.
@Test
@Parameters({"username", "password", "role", "status"})
public void userTest(
String username,
String password,
String role,
String status) {
System.out.println(username);
System.out.println(password);
System.out.println(role);
System.out.println(status);
}
TestNG parameters can be defined at different levels. A parameter can be configured at suite level or test level depending on how it needs to be shared.
<suite name="Suite">
<parameter name="browser" value="chrome"/>
<test name="Test">
<classes>
<class name="LoginTest"/>
</classes>
</test>
</suite>
A suite-level parameter can provide a common value to tests in the suite unless a more specific parameter overrides it.
<suite name="Automation Suite">
<parameter name="browser" value="chrome"/>
<test name="Login Test">
<classes>
<class name="LoginTest"/>
</classes>
</test>
</suite>
A test-level parameter can be defined inside a specific <test> element.
<suite name="Suite">
<test name="Firefox Test">
<parameter name="browser" value="firefox"/>
<classes>
<class name="BrowserTest"/>
</classes>
</test>
</suite>
More specific parameter definitions can override broader values. This is useful when most tests use one configuration but a particular test requires another.
<suite name="Suite">
<parameter name="browser" value="chrome"/>
<test name="Firefox Test">
<parameter name="browser" value="firefox"/>
<classes>
<class name="BrowserTest"/>
</classes>
</test>
</suite>
TestNG provides the @Optional annotation for supplying a default value when a named parameter is not provided.
import org.testng.annotations.Optional;
import org.testng.annotations.Parameters;
@Test
@Parameters("browser")
public void browserTest(
@Optional("chrome") String browser) {
System.out.println("Browser: " + browser);
}
If the browser parameter is not supplied, the test can use Chrome as the default value.
Configuration methods can also receive parameters.
@BeforeMethod
@Parameters("browser")
public void setup(String browser) {
System.out.println(
"Starting browser: " + browser
);
}
@BeforeTest
@Parameters("environment")
public void setupEnvironment(String environment) {
System.out.println(
"Environment: " + environment
);
}
This can be useful when test setup depends on an environment or configuration value.
@BeforeSuite
@Parameters("browser")
public void suiteSetup(String browser) {
System.out.println(
"Suite Browser: " + browser
);
}
The parameter must be available within the relevant configuration scope.
Parameterized tests work effectively with the Page Object Model. Test data is supplied to the test layer while page classes handle application interactions.
Test Data
|
v
Parameterized Test
|
v
Page Object
|
v
WebDriver
|
v
Application
public class LoginPage {
private WebDriver driver;
private By username =
By.id("username");
private By password =
By.id("password");
private By loginButton =
By.id("loginButton");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void login(
String user,
String pass) {
driver.findElement(username)
.sendKeys(user);
driver.findElement(password)
.sendKeys(pass);
driver.findElement(loginButton)
.click();
}
}
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(
String username,
String password) {
LoginPage loginPage =
new LoginPage(driver);
loginPage.login(
username,
password
);
}
@DataProvider(name = "searchData")
public Object[][] searchData() {
return new Object[][] {
{"Laptop"},
{"Mobile"},
{"Headphones"},
{"Keyboard"},
{"Mouse"}
};
}
@Test(dataProvider = "searchData")
public void searchTest(String keyword) {
driver.findElement(By.id("search"))
.clear();
driver.findElement(By.id("search"))
.sendKeys(keyword);
driver.findElement(By.id("searchButton"))
.click();
}
@DataProvider(name = "registrationData")
public Object[][] registrationData() {
return new Object[][] {
{"John", "[email protected]", "9876543210"},
{"David", "[email protected]", "9876543211"},
{"Robert", "[email protected]", "9876543212"}
};
}
@Test(dataProvider = "registrationData")
public void registrationTest(
String name,
String email,
String mobile) {
System.out.println(name);
System.out.println(email);
System.out.println(mobile);
}
E-commerce automation frequently requires different products, quantities, categories, and discount combinations.
@DataProvider(name = "productData")
public Object[][] productData() {
return new Object[][] {
{"Laptop", 1},
{"Mobile", 2},
{"Headphones", 3}
};
}
@Test(dataProvider = "productData")
public void productTest(
String product,
int quantity) {
System.out.println(product);
System.out.println(quantity);
}
@DataProvider(name = "roles")
public Object[][] roles() {
return new Object[][] {
{"Admin"},
{"Manager"},
{"Employee"},
{"Customer"}
};
}
@Test(dataProvider = "roles")
public void roleTest(String role) {
System.out.println(
"Testing role: " + role
);
}
@DataProvider(name = "browsers")
public Object[][] browsers() {
return new Object[][] {
{"chrome"},
{"firefox"},
{"edge"}
};
}
@Test(dataProvider = "browsers")
public void browserTest(String browser) {
System.out.println(
"Running on: " + browser
);
}
For a complete browser framework, the browser value can be passed to a reusable DriverFactory.
@DataProvider(name = "environments")
public Object[][] environments() {
return new Object[][] {
{"QA", "https://qa.example.com"},
{"Stage", "https://stage.example.com"},
{"Production", "https://www.example.com"}
};
}
@Test(dataProvider = "environments")
public void environmentTest(
String environment,
String url) {
System.out.println(environment);
System.out.println(url);
}
For large projects, test data does not always need to be hard-coded inside Java classes. A parameterized test can obtain its data from external sources.
Apache POI can be used to read Excel files and convert rows into data supplied by a DataProvider.
@DataProvider(name = "excelData")
public Object[][] excelData() {
// Excel reading logic can be implemented here.
return new Object[][] {
{"user1", "pass1"},
{"user2", "pass2"},
{"user3", "pass3"}
};
}
@DataProvider(name = "csvData")
public Object[][] csvData() {
// CSV reading logic can be implemented here.
return new Object[][] {
{"John", "[email protected]"},
{"David", "[email protected]"}
};
}
JSON is frequently used for test data in modern automation frameworks.
@DataProvider(name = "jsonData")
public Object[][] jsonData() {
return new Object[][] {
{"Chrome", "https://example.com"},
{"Firefox", "https://example.com"}
};
}
Database-driven parameterization can retrieve records dynamically and pass them to test methods.
@DataProvider(name = "databaseData")
public Object[][] databaseData() {
// Database connection and query
// logic can be implemented here.
return new Object[][] {
{"user1", "active"},
{"user2", "inactive"}
};
}
Expected results can be included in test data and compared against actual application behavior.
@DataProvider(name = "calculatorData")
public Object[][] calculatorData() {
return new Object[][] {
{10, 20, 30},
{5, 5, 10},
{100, 25, 125}
};
}
@Test(dataProvider = "calculatorData")
public void additionTest(
int a,
int b,
int expected) {
int actual = a + b;
Assert.assertEquals(
actual,
expected
);
}
Each invocation of a parameterized test can be represented as a separate test execution in TestNG reporting systems.
LoginTest
|
|-- admin / admin123 PASS
|-- manager / manager123 PASS
|-- invalid / wrong123 FAIL
Test reports should make it possible to identify which test data caused a failure. Sensitive values such as passwords should not be exposed in reports or logs.
Parameterized TestNG tests can be executed through Maven like regular TestNG tests.
mvn testMaven can manage dependencies, build the project, execute the tests, and integrate results with CI/CD systems.
Parameterized tests are useful in CI/CD because the same automation suite can execute with different configurations and data sets.
Developer Commit
|
v
CI/CD Pipeline
|
v
Maven Build
|
v
TestNG
|
v
Parameterized Tests
|
v
Selenium WebDriver
|
v
Application
|
v
Reports
Jenkins can trigger Maven-based Selenium TestNG suites. Parameters can be supplied through pipeline configuration, environment variables, Maven properties, or TestNG configuration depending on the framework architecture.
Jenkins
|
v
Build
|
v
Maven
|
v
TestNG
|
v
Parameterized Test
|
v
Selenium
|
v
Test Report
Parameterized test invocations can be executed in parallel when the framework is designed for thread safety.
@DataProvider(
name = "users",
parallel = true
)
public Object[][] users() {
return new Object[][] {
{"user1"},
{"user2"},
{"user3"},
{"user4"}
};
}
Parallel execution should be used carefully because concurrent Selenium tests should not share WebDriver instances or mutable state unsafely.
When multiple parameterized tests execute simultaneously, each test should generally have an isolated browser session and isolated test state.
Data Provider
|
+---- Thread 1 ---- WebDriver 1
|
+---- Thread 2 ---- WebDriver 2
|
+---- Thread 3 ---- WebDriver 3
|
v
Independent Test Execution
A common framework approach is to use a thread-safe DriverFactory or ThreadLocal-based driver management when parallel execution requires it.
A DriverFactory can centralize browser creation while parameterized tests provide the browser value.
public class DriverFactory {
public static WebDriver createDriver(
String browser) {
if (browser.equalsIgnoreCase("chrome")) {
return new ChromeDriver();
}
if (browser.equalsIgnoreCase("firefox")) {
return new FirefoxDriver();
}
if (browser.equalsIgnoreCase("edge")) {
return new EdgeDriver();
}
throw new IllegalArgumentException(
"Unsupported browser: " + browser
);
}
}
TestNG Starts
|
v
Read Parameters
|
v
Create Test Configuration
|
v
Create WebDriver
|
v
Execute Test
|
v
Perform Assertions
|
v
Capture Result
|
v
Execute Next Data Set
|
v
Generate Report
| Hard-Coded Test | Parameterized Test |
|---|---|
| Values are directly written in test code | Values are supplied externally or through data mechanisms |
| More duplication | Less duplication |
| Difficult to scale | Easy to expand |
| Lower reusability | Higher reusability |
| Changing data may require code changes | Data can often be changed independently |
Parameterized testing is the mechanism of supplying variable inputs to reusable test logic. Data-driven testing is a broader testing approach where test data is separated from test logic and multiple data sets are used systematically.
TestNG DataProviders are one common implementation of data-driven parameterization.
The term parameterized test can refer broadly to tests receiving variable values. TestNG's @Parameters is specifically designed for named parameters, often configuration-oriented values from XML.
For example:
@Parameters({"browser", "url"})
public void test(String browser, String url) {
}
This is different from a DataProvider that supplies many rows of test data.
Regression testing often requires the same workflow to be validated with different inputs after application changes.
For example, a search regression test can use many search keywords while keeping the test logic unchanged.
Search Test
|
+-- Laptop
+-- Mobile
+-- Tablet
+-- Headphones
+-- Keyboard
+-- Mouse
E-commerce applications provide many practical parameterization scenarios.
| Scenario | Possible Parameters |
|---|---|
| Login | Username, password |
| Search | Keyword |
| Product | Product name, quantity |
| Filters | Category, price range, brand |
| Checkout | Address, payment method |
| Discount | Coupon code |
| User Role | Admin, manager, customer |
The same parameterized test-data concepts can be used across UI and API automation. For example, a set of user records can be used to validate API responses and corresponding UI behavior.
Common Test Data
|
+---- API Test
|
+---- UI Test
|
+---- Database Validation
|
v
Reusable Test Data
The name referenced in the test method must match the configured parameter name.
Incorrect configuration:
<parameter name="browserName" value="chrome"/>Incorrect Java code:
@Parameters("browser")
public void test(String browser) {
}
Correct Java code:
@Parameters("browserName")
public void test(String browser) {
}
When using multiple parameters, the test method should accept the expected number of values.
@Parameters({"username", "password", "role"})
public void test(
String username,
String password,
String role) {
}
If the configuration does not supply the required values, TestNG may report a parameter-related execution error.
Browser parameters should be validated before creating a WebDriver instance.
if (browser.equalsIgnoreCase("chrome")) {
driver = new ChromeDriver();
} else if (browser.equalsIgnoreCase("firefox")) {
driver = new FirefoxDriver();
} else if (browser.equalsIgnoreCase("edge")) {
driver = new EdgeDriver();
} else {
throw new IllegalArgumentException(
"Unsupported browser: " + browser
);
}
Tests should validate required parameters before using them.
if (username == null || username.trim().isEmpty()) {
throw new IllegalArgumentException(
"Username cannot be empty"
);
}
Proper validation helps produce clearer failures and makes debugging easier.
Logging should identify the important test parameters so that failed executions can be investigated.
System.out.println(
"Executing login test for user: "
+ username
);
Do not log passwords, authentication tokens, API keys, or other secrets in plain text.
Parameterized executions should be clearly identifiable in reports. A useful report can show the test name, browser, environment, input category, status, duration, and failure reason.
| Test | Browser | Environment | Status |
|---|---|---|---|
| Login | Chrome | QA | PASS |
| Login | Firefox | QA | PASS |
| Login | Edge | QA | FAIL |
src
|-- test
|-- java
|-- tests
| |-- LoginTest.java
| |-- SearchTest.java
| |-- CheckoutTest.java
|
|-- pages
| |-- LoginPage.java
| |-- SearchPage.java
| |-- CheckoutPage.java
|
|-- data
| |-- LoginDataProvider.java
| |-- SearchDataProvider.java
| |-- ProductDataProvider.java
|
|-- utilities
|-- DriverFactory.java
|-- ExcelReader.java
|-- ConfigReader.java
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class LoginTest {
WebDriver driver;
@BeforeMethod
public void setup() {
driver = new ChromeDriver();
driver.manage().window().maximize();
driver.get("https://example.com/login");
}
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(
String username,
String password) {
driver.findElement(
By.id("username")
).sendKeys(username);
driver.findElement(
By.id("password")
).sendKeys(password);
driver.findElement(
By.id("loginButton")
).click();
Assert.assertTrue(
driver.getTitle().contains("Dashboard")
);
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.edge.EdgeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
public class CrossBrowserTest {
WebDriver driver;
@BeforeMethod
@Parameters("browser")
public void setup(String browser) {
if (browser.equalsIgnoreCase("chrome")) {
driver = new ChromeDriver();
} else if (browser.equalsIgnoreCase("firefox")) {
driver = new FirefoxDriver();
} else if (browser.equalsIgnoreCase("edge")) {
driver = new EdgeDriver();
} else {
throw new IllegalArgumentException(
"Unsupported browser: " + browser
);
}
driver.manage().window().maximize();
}
@Test
@Parameters("url")
public void applicationTest(String url) {
driver.get(url);
System.out.println(
"Testing URL: " + url
);
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
<suite name="Cross Browser Suite">
<test name="Chrome Test">
<parameter name="browser" value="chrome"/>
<parameter name="url" value="https://example.com"/>
<classes>
<class name="CrossBrowserTest"/>
</classes>
</test>
<test name="Firefox Test">
<parameter name="browser" value="firefox"/>
<parameter name="url" value="https://example.com"/>
<classes>
<class name="CrossBrowserTest"/>
</classes>
</test>
<test name="Edge Test">
<parameter name="browser" value="edge"/>
<parameter name="url" value="https://example.com"/>
<classes>
<class name="CrossBrowserTest"/>
</classes>
</test>
</suite>
Test Configuration
|
v
+---------+---------+
| |
Browser URL
| |
+---------+---------+
|
v
TestNG Test
|
v
Data Provider
|
v
Test Method
|
v
Page Objects
|
v
Selenium WebDriver
|
v
Application
|
v
Assertions
|
v
Reports
A mature Selenium framework can combine parameterization with several automation components.
| Component | Responsibility |
|---|---|
| TestNG | Test execution and parameter management |
| DataProvider | Multiple test-data sets |
| @Parameters | Configuration values |
| Page Object Model | Page interaction logic |
| DriverFactory | Browser creation |
| Excel/CSV/JSON | External test data |
| Maven | Build and dependency management |
| Jenkins | CI/CD execution |
| ExtentReports/Allure | Test reporting |
| Git/GitHub | Version control |
A parameterized test is a reusable test method that receives different input values during different executions.
It allows the same Selenium workflow to be tested with different browsers, credentials, URLs, search values, roles, and other inputs.
The @Parameters annotation is used to receive named parameters from TestNG configuration.
@DataProvider is a TestNG annotation used to supply multiple sets of test data to a test method.
@Parameters is commonly used for configuration-style values, while @DataProvider is designed for multiple test-data sets and data-driven execution.
Yes. Selenium tests can receive parameters through TestNG and use those values during browser automation.
Yes. Browser names can be supplied through @Parameters or DataProvider and passed to a DriverFactory.
Yes. URLs are commonly parameterized to execute tests against different environments.
Yes. Test data can be supplied to test classes while page objects manage application interactions.
Yes. A DataProvider can use parallel = true, provided the automation framework is thread-safe.
@Optional allows a default value to be specified when a TestNG parameter is not supplied.
Yes. Excel, CSV, JSON, databases, and other sources can provide test data.
Passwords and other secrets should not normally be stored as plain text in source-controlled automation code or reports.
It separates reusable test logic from variable input values, reducing duplicate test code.
Depending on the configuration and annotation usage, TestNG can report a missing parameter error or use a value supplied through @Optional.
It is the practice of supplying browser names as test configuration or test data so that the same test can run against multiple browsers.
It is the practice of supplying environment-specific values such as QA, staging, or production URLs to reusable tests.
Yes. Maven can execute TestNG-based parameterized tests as part of the project build.
Yes. Parameterized Selenium suites can run in CI/CD pipelines with different environments and configurations.
The major benefit is that reusable test logic can validate many input combinations without creating duplicate test methods.
| Concept | Purpose |
|---|---|
| Parameterized Test | Runs reusable test logic with variable inputs |
| @Parameters | Receives named TestNG parameters |
| @DataProvider | Provides multiple test-data sets |
| @Optional | Provides a default parameter value |
| testng.xml | Defines TestNG configuration and parameters |
| POM | Separates page interaction logic from tests |
| DriverFactory | Creates browser-specific WebDriver instances |
| Excel | External test-data source |
| CSV | External test-data source |
| JSON | Structured external test-data source |
| Database | Dynamic test-data source |
| parallel = true | Enables parallel DataProvider invocations |
Consider an e-commerce application where the QA team needs to test login functionality on multiple browsers and search functionality with multiple products.
Browser Data
|
+-- Chrome
+-- Firefox
+-- Edge
|
v
Browser Configuration
|
v
Selenium WebDriver
|
v
Login Test
|
+-- Admin
+-- Manager
+-- Employee
|
v
Search Test
|
+-- Laptop
+-- Mobile
+-- Tablet
+-- Headphones
|
v
Assertions
|
v
Test Report
Instead of creating separate test methods for every combination, the framework can reuse the same automation logic and change the parameters or test-data sets.
Parameterized Tests are an important part of modern Selenium automation frameworks because they allow the same test logic to execute with different input values.
TestNG provides @Parameters for named configuration values and @DataProvider for multiple sets of test data. These features can be used for browser selection, environment URLs, login credentials, search values, user roles, product data, expected results, and many other testing scenarios.
Parameterized tests become especially powerful when combined with Selenium WebDriver, Page Object Model, DriverFactory, external test data, assertions, Maven, CI/CD, parallel execution, and reporting tools.
A well-designed parameterized framework keeps test logic reusable, test data manageable, browser and environment configuration flexible, and test execution scalable.
Learn more about Selenium automation, TestNG, framework development, and practical automation testing:
Final Takeaway: Parameterized testing helps Selenium automation frameworks become reusable, scalable, maintainable, and data-driven. Use @Parameters for configuration-oriented values and @DataProvider when the same test needs to execute against multiple data sets.
